Timestamp-based matching of identifiers

ABSTRACT

Systems and methods for timestamp-based matching of identifiers are provided. Information may be stored in memory regarding a plurality of identifiers each unique to an associated website or to an associated browser. Stored information may further include one or more maps each associating a device identifier with at least one immutable browser identifier or mutable browser identifier. The device identifier may be unique to an associated computing device. Information may be received from a computing device that has used a browser to download a website, where the downloaded website includes a reference to a browser identifier specific to the downloaded website. The received information may be determined to include a timestamp and an internet protocol (IP) address. The timestamp and IP in the received information may further be determined to correspond to a computing device associated with one of the stored maps, where the corresponding computing device is identified by a corresponding device identifier. The stored map associated with the corresponding device identifier may be updated based on the referenced browser identifier.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present patent application is a continuation and claims the prioritybenefit of U.S. patent application Ser. No. 14/861,993 filed Sep. 22,2015, now U.S. Pat. No. 10,491,451, which is related to co-pending U.S.patent application Ser. No. 14/716,187 filed May 19, 2015, now U.S. Pat.No. 9,342,617 and co-pending U.S. patent application Ser. No.14/861,097, now U.S. Pat. No. 10,103,931, the disclosures of which areincorporated by reference herein.

BACKGROUND Field of the Invention

The present invention generally relates to websites. More specifically,the present invention relates to timestamp-based matching ofidentifiers.

Description of the Related Art

The use of Internet and web resources is nearly ubiquitous throughoutthe industrialized world. Users generally access the Internet using anyof a number of computing devices capable of communicating over acommunication network, whether wirelessly or through wired connections.More specifically, the user may use a browser application on a computingdevice to access content on any of a number of webpages and websiteshosted by one or more web servers.

Upon request, content related to a designated webpage may be downloadedto the user computing device, which may further render the webpage to bedisplayed. Such downloaded content may include a variety of differenttypes of files, including documents, graphics, audio and video, etc., aswell as related data (e.g., metadata, stylesheets including cascadingstylesheets). The downloaded content may be stored in a browser cache inlocal memory of the computing device. Various elements and components ofa particular webpage or website may change over time (e.g., as apublisher publishes new or updated content). Some components orelements, however, remain static and unchanged. When the user leaves thewebpage and later wishes to return, the browser cache allows thecomputing device to retrieve static, unchanged files related to theassociated webpage from local memory, rather than re-downloading thesame web objects when a user wishes to revisit the webpage.

Currently, browsers do not contain or expose any unique identifiers thatcan be accessed and used by websites. Present websites and webpages maytrack and share data regarding the activity (e.g., repeat visits) of theuser in relation to a particular webpage. Such data may include stateinformation (e.g., preferences, shopping cart items), provideregistration or authentication information (e.g., user names, passwords,addresses/locations), or otherwise track browsing history (e.g., whichwebpages were visited, a number of visits, when the visits occurred).Because nearly all aspects of modern life may be reflected in orotherwise involve Internet activity, however, some of the tracked datamay be personally identifiable of a particular individual. Trackingmechanisms that encompass such personally identifiable data maytherefore risk exposure of personal, confidential, and/or otherwisesensitive user information. In the interests of protecting user privacy,some jurisdictions may even have statutes or regulations restricting thetype of data that may be tracked.

Meanwhile, various publishers, service providers, and related entitiesmay be interested in obtaining statistical data regarding the usertraffic that visits a given webpage or website. Although a web servermay be able to identify a number of download requests for a particularwebpage, such requests may be made by the same user (or the same smallset of users). Such a metric may therefore fail to present an accuratepicture of the traffic or user activity involving the website, whileusing the more particularized data discussed above may risk exposure ofinformation that is personally identifiable of a specific user.

Moreover, users may use different browsers and visit a variety ofdifferent websites. Such variety can complicate the ability to tracktraffic where, for example, a user may use different browsers to visitthe same website. Because such different browsers generally do notcommunicate or exchange information, it can be quite difficult to get afull picture of such a user may traffic the Internet.

There is, therefore, a need in the art for improved systems and methodsfor matching browser identifiers to a browser and/or device.

SUMMARY OF THE CLAIMED INVENTION

Embodiments of the present invention allow for timestamp-based matchingof identifiers. Information may be stored in memory regarding aplurality of identifiers each unique to an associated website or to anassociated browser. Stored information may further include one or moremaps each associating a device identifier with at least one browseridentifier. The device identifier may be unique to an associatedcomputing device. Information may be received from a computing devicethat has used a browser to download a website, where the downloadedwebsite includes a reference to a browser identifier specific to thedownloaded website. The received information may be determined toinclude a timestamp and an internet protocol (IP) address. The timestampand IP in the received information may further be determined tocorrespond to a computing device associated with one of the stored maps,where the corresponding computing device is identified by acorresponding device identifier. The stored map associated with thecorresponding device identifier may be updated based on the referencedbrowser identifier.

Various embodiments may include methods for timestamp-based matching ofidentifiers. Such methods may include storing information in memoryregarding one or more maps where each map associates a device identifierunique to an associated computing device with at least one browseridentifier, receiving information from a computing device that has useda browser to download a website that includes a reference to a browseridentifier specific to the browser, identifying that the receivedinformation includes a timestamp and an internet protocol (IP) address,determining that the timestamp and the IP address in the receivedinformation corresponds to a device identifier in one of the stored mapswhere the corresponding device identifier is specific to the computingdevice, and updating the stored map associated with the correspondingdevice identifier based on the referenced browser identifier.

Additional embodiments may include server systems for timestamp-basedmatching of identifiers. Such systems may include memory that storesinformation regarding one or more maps where each map associates adevice identifier unique to an associated computing device with at leastone browser identifier, a communication interface that receivesinformation from a computing device that has used a browser to downloada website that includes a reference to a browser identifier specific tothe browser; and a processor that executes instructions to identify thatthe received information includes a timestamp and an internet protocol(IP) address, to determine that the timestamp and the IP address in thereceived information corresponds to a device identifier in one of thestored maps where the corresponding device identifier is specific to thecomputing device, and to update the stored map associated with thecorresponding device identifier based on the referenced browseridentifier.

Further embodiments include non-transitory computer-readable storagemedia having embodied thereon a program executable by a processor toperform a method for timestamp-based matching of identifiers asdescribed above.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates an exemplary network environment in which a systemfor timestamp-based matching of identifiers may be implemented.

FIG. 2 is a flowchart illustrating an exemplary method fortimestamp-based matching of identifiers.

FIG. 3 illustrates an exemplary computing system that may be used toimplement an embodiment of the present invention

DETAILED DESCRIPTION

Embodiments of the present invention allow for timestamp-based matchingof identifiers. Information may be stored in memory regarding aplurality of identifiers each unique to an associated website or to anassociated browser. Stored information may further include one or moremaps each associating a device identifier with at least one browseridentifier. The device identifier may be unique to an associatedcomputing device. Information may be received from a computing devicethat has used a browser to download a website, where the downloadedwebsite includes a reference to a browser identifier specific to thedownloaded website. The received information may be determined toinclude a timestamp and an internet protocol (IP) address. The timestampand IP in the received information may further be determined tocorrespond to a computing device associated with one of the stored maps,where the corresponding computing device is identified by acorresponding device identifier. The stored map associated with thecorresponding device identifier may be updated based on the referencedbrowser identifier.

FIG. 1 illustrates a network environment 100 in which a system formatching mutable browser identifiers may be implemented. Networkenvironment 100 may include a communication network 110, one or moreuser devices 120A-D, web server 130, identifier server 140, and one ormore service providers 150. Devices in network environment 100 maycommunicate with each other via communications network 110.

Communication network 110 may be a local, proprietary network (e.g., anintranet) and/or may be a part of a larger wide-area network. Thecommunications network 110 may be a local area network (LAN), which maybe communicatively coupled to a wide area network (WAN) such as theInternet. The Internet is a broad network of interconnected computersand servers allowing for the transmission and exchange of InternetProtocol (IP) data between users connected through a network serviceprovider. Examples of network service providers are the public switchedtelephone network, cellular or mobile service providers, a cable serviceprovider, a provider of digital subscriber line (DSL) services, or asatellite service provider. Communications network 110 allows forcommunication between the various components of network environment 100.

Users may use any number of different electronic user devices 120A-D,such as general purpose computers, mobile phones, smartphones,smartwatches, wearable devices, personal digital assistants (PDAs),portable computing devices (e.g., laptop, netbook, tablets), desktopcomputing devices, handheld computing device, or any other type ofcomputing device capable of communicating over communication network110. User devices 120 may also be configured to access data from otherstorage media, such as local caches, memory cards, or disk drives as maybe appropriate in the case of downloaded services. User device 120 mayinclude standard hardware computing components such as network and mediainterfaces, non-transitory computer-readable storage (memory), andprocessors for executing instructions that may be stored in memory.

In addition, user devices 120 may include a variety of applications,including browser applications that allow the user to request certainwebpages. As used herein, references to browser and browser identifierare exemplary, and teachings regarding the same are applicable to othertypes of applications and application identifiers (e.g., Apple IDFA,Google AdID). For example, a user may enter a uniform resource locator(URL) into a browser application. Such a browser may send such requestto an associated web server (e.g., web server 130), receive responsivedata (e.g., webpage file with references to other files to download),and use such responsive data to render and display the requestedwebpage. Webpage files that may be downloaded to the user device 120 mayinclude not only files corresponding to content that is actuallydisplayed as part of the webpage, but also associated files.

Web server 130, identifier server 140, and service providers 150 mayinclude any type of server or other computing device as is known in theart, including standard hardware computing components such as networkand media interfaces, non-transitory computer-readable storage (memory),and processors for executing instructions or accessing information thatmay be stored in memory. The functionalities of multiple servers may beintegrated into a single server. Any of the aforementioned servers (oran integrated server) may take on certain client-side, cache, or proxyserver characteristics. These characteristics may depend on theparticular network placement of the server or certain configurations ofthe server.

Web server 130 may be any kind of server used to host web content,including any type of webpage or website data. The particular filesassociated with each website may be controlled by a publisher (ordesignated administrator). The website file may include links to filesunder control by other parties. In that regard, the website filesdownloaded from web server 130 may include a reference (e.g., URL) to amutable browser identifier file, as well as an optional loaderapplication (e.g., Javascript commands) and associated code library tobe used with the mutable browser identifier file. Such mutable browseridentifier file may be specific to the website. For example, a mutablebrowser identifier for a particular website may include or otherwise bebased on a domain (or other characteristic) of that website. As such,each website visited by a particular user device may be associated witha unique and different mutable browser identifier.

Such mutable browser identifier may be generated and managed in mannerssimilar to those disclosed with respect to the browser identifiersdisclosed in related co-pending U.S. patent application Ser. No.14/716,187, the disclosure of which has been incorporated by referenceherein. Moreover, the mutable browser identifiers disclosed herein maybe used in conjunction with the disclosed invention of related U.S.patent application Ser. No. 14/716,187. As indicated by their respectivenames, an immutable browser identifier does not change, while a mutablebrowser identifier may change. An immutable browser identifier may beassociated or mapped to different mutable browser identifiers. Because amutable browser identifier may change, various indicators associatedwith a referenced mutable browser identifier may be used to map thatreferenced browser identifier to the immutable browser identifier, itsassociated mutable browser identifiers, and/or an associated deviceidentifier.

In that regard, the browser may attempt to access the referenced mutablebrowser identifier file, either automatically or under direction of theloader application as executed by the user device 120. Such access mayinclude automatically checking a local browser cache to determinewhether the referenced mutable browser identifier file may have alreadybeen downloaded previously.

Following such checking of the local browser cache, the user device 120may send a request to an identifier server 140 associated with thereferenced mutable browser identifier file. Such request may beindicative of whether the referenced mutable browser identifier file wasfound in the local browser cache (and if so, when the referenced mutablebrowser identifier file had last been modified). Where the requestindicates that the referenced mutable browser identifier file was notfound in the local browser cache, the identifier server 140 may respondby sending a new mutable browser identifier file to the user device 120.As noted above, the new mutable browser identifier may be generated soas to be unique to the particular website being downloaded (e.g., basedon website domain or other characteristic).

In that regard, the identifier server 140 may generate and provide a newunique mutable browser identifier upon request. Such a unique mutablebrowser identifier may be specific to the website making the request.Where the user may have opted out, however, a non-unique term may beinserted in place of the unique mutable browser identifier. In someembodiments, the user may opt out of being provided with uniqueidentifiers with respect to a designated webpage or website.Alternatively, the user may opt into being provided with uniqueidentifiers with respect to a designated webpage or website. As such,the website may be uniquely identified via the unique mutable browseridentifier for some webpages, but not others. In some embodiments, suchinformation regarding user opt-outs or opt-ins may be reflected in themutable browser identifier file. For example, the mutable browseridentifier file may include information indicative of the user opt-in oropt-out for defined webpages, websites, or categories of websites, aswell as indicators specifying the granular details under which theopt-in or opt-out are to be implemented.

The user may also opt to reset the unique mutable browser identifierassociated with the website. Resetting the unique mutable browseridentifier may involve clearing the local browser cache of anypreviously downloaded mutable browser identifier files, generating a newmutable browser identifier (in a new mutable browser identifier file),and providing the new mutable browser identifier file, which may then becached in the local browser cache. In some embodiments, a signal may besent to the identifier server 140 to indicate that the mutable browseridentifier file needs to be updated. Such a signal may be implemented ina cookie that the identifier server 140 can read and then determine whatto send back as the mutable browser identifier file. Alternatively, therequest (including pass information or parameters) may be directed to atransient URL (e.g., that is structured to include the mutable browseridentifier and any directives), and that request may then be redirectedto the identifier server 140, which can then look at the referrer header(e.g., transient URL) of the request to parse out the requested changesto the mutable browser identifier file.

Further, the identifier server 140 may provide a plurality of mutablebrowser identifiers (each to a different website and provided in adifferent mutable browser identifier file). Activity at the user device120 in relation to the website may thereafter be associated with theprovided unique mutable browser identifier. Such mutable browseridentifier may further be associated with immutable browser and/ordevice identifiers, thereby allowing for the ability to distinguishbetween different browsers on the same or different computing devices insome cases. Specifically, information may be logged regarding activityat a particular website (as identified by a unique mutable browseridentifier), which may be provided to identifier server 140 (or anassociated server) by a loader application at the user device 120. Inthat regard, the identifier server 140 may not receive the mutablebrowser identifier itself, as the mutable browser identifier may only becalled by local applications or code (e.g., browser, loader application,local code library) resident on the user device 120. The loaderapplication may be executed to perform a variety of functions, which mayinclude loading and executing code from the code library. Such a codelibrary may be provided, modified, and updated at the web server 130,identifier server 140, or other designated service provider 150.

Where the referenced mutable browser identifier file was indeed found inthe local browser cache, the browser may send a request with anindicator (e.g., a “if-modified-since” header) regarding the referencedmutable browser identifier file to the identifier server 140. Theidentifier server 140 may then determine whether an updated version ofthe referenced mutable browser identifier file should be sent based oninformation provided in the request (e.g., whether or not a“if-modified-since” header exists for the referenced mutable browseridentifier file) or associated cookies, referrer headers, etc. If thereferenced mutable browser identifier file is determined to be in thelocal browser cache (e.g., as indicated by the existence of anassociated “if-modified-since” header in the request), the identifierserver 140 may validate the file and send an indicator (e.g., a “304 notmodified” indicator) regarding such validation. In some embodiments,such validation may extend a maximum age or expiration date/term of thereferenced mutable browser identifier file, whereby the referencedmutable browser identifier file may be maintained an extended period oftime (corresponding to the extended maximum age or expiration date/term)in the local browser cache. Where the user may have opted out (e.g., asindicated by an opt-out cookie), however, the identifier server 140 mayreturn a mutable browser identifier file with a non-unique mutablebrowser identifier or an opt-out identifier.

The browser may not necessarily request that the identifier server 140validate the referenced mutable browser identifier file in someinstances. In such instances, the browser may use the cached mutablebrowser identifier file without making any request to the identifierserver 140.

In some cases, the referenced mutable browser identifier file may bedetermined to require an update. For example, a cookie without an“if-modified-since” header may indicate that the referenced mutablebrowser identifier file had previously been present but is no longerfound (in whole or in part) in the local browser cache. Upon determiningthat such modification may have occurred (e.g., as indicated by a headeror other indicator in the request), the identifier server 140 mayrecreate the referenced website file or send a new mutable browseridentifier file to the user device 120. While the foregoing refersprimarily to modification headers, any type of cache control headers (orany type of cache control commands) known in the art may be used. Cachecontrol may involve any operation involving cache memory, includingdirecting validation and adjusting maximum ages as desired, as well ascontrol where the mutable browser identifier file is cached (e.g.,specify local browser cache).

A mutable browser identifier file may be any type of file that may becached in local browser cache memory, including stylesheets, JavaScriptfiles, HTML files, text files, AJAX requests, image files, etc. Suchmutable browser identifier file may allow for its content (including themutable browser identifier, whether unique or non-unique) to beaccessible to the browser and related browser applications (including aloader application). As such, the browser and related browserapplications may access and use the mutable browser identifier forvarious operations, including logging activity.

A mutable browser identifier file may include a mutable browseridentifier, which may be unique to the webpage. In some cases, the usermay opt out of being provided with a unique mutable browser identifier.In such cases, a new mutable browser identifier file may be generatedwith a non-unique term as the mutable browser identifier. Alternatively,the mutable browser identifier file may be updated to replace the uniqueidentifier with a non-unique term (or an opt-out identifier for definedor general opt-out).

In some embodiments, the mutable browser identifier file may furtherinclude other types of information regarding user preferences (asdesignated by the user), including information regarding user opt-outsor opt-ins for specific webpages. As the user changes their opt-out oropt-in settings, such information may be used to update a mutablebrowser identifier file. The browser may then be directed to reload themutable browser identifier file into the local browser cache, therebyimplementing the updated user settings.

The identifier server 140 may further be able to match mutable browseridentifiers to a common immutable browser identifier and in some cases,to a common device identifier. In this regard, a particular user device120 (as identified by a device identifier) may be associated with one ormore browsers (as identified by a respective immutable browseridentifier), each of which may be associated with one or more websites(as identified by a respective mutable browser identifier). Theidentifier server 140 may therefore be capable of identifying one ormore such identifiers (whether website, browser, or device) when a userdevice requests a website using particular browser, as well asmaintaining and updating maps regarding which identifiers are associatedwith each other.

The identifier server 140 may use various indicators to create andupdate such maps. For example, secure sessions (e.g., secure socketlayer (SSL) sessions) may allow for session resumption, which occurswhere a client and server negotiates SSL information and then laterreuses that negotiated SSL information for future connections. SSLsession setup is generally very time-consuming, so not having torenegotiate is therefore desirable. In order to resume a session, aclient must be able to identify the session. SSL session IDs and TLSsession tickets are two mechanisms that allow for the identification andresumption of a previous session.

The identifier server 140 may be called when a browser visits websiteswith certain scripts (e.g., that call on the domain of the identifierserver 140). The identifier server 140 may therefore be able to receivesession resumption data when a particular website is accessed. As such,such identifier server 140 may use such session information to determinewhen multiple connections are using the same session as indicated, forexample, by the same SSL session ID. Thus, the identifier server 140 canthen map browser IDs associated with the multiple connections together.Such a map constructed by the identifier server 140 allows for creationof a persistent set of indicators that can be used to recognize abrowser even when there is not existing SSL session.

Additional indicators may be based on use of transmission controlprotocol (TCP) information. TCP is used by a variety of Internet-basedapplications, including web browsers, email, and other applications.Information associated with use of TCP by a particular device (e.g.,present in a TCP packet) may be inclusive or indicative of varioustimestamp information, such as current time, uptime, and clock skew. Inan exemplary embodiment, the identifier server 140 may receive a browseridentifier (e.g., associated with TCP timestamp information, such as aparticular current time, uptime, source IP address, clock skew),determine whether the associated timestamp information (e.g., uptime)matches any timestamp information previously associated with the browseridentifier (and if not, update stored information regarding the browseridentifier to include the associated timestamp information), determinewhether the uptime (or source IP address or clock skew) maps to anydevice identifiers, and if so, mapping the device identifiers together.

While current time are generally included in the TCP packet, furthercalculations may also be applied to obtain other timestamp information(e.g., uptime and clock skew). Uptime, for example, provides a measureof time since a computing device was started and continuously working.Especially when combined with other indicators (e.g., source IP address,clock skew), the uptime may be able to uniquely identify a particulardevice for the duration of time before the computing device isrestarted. With respect to uptime, a device may record and report anumber of ticks since the last time the device was started or the numberof ticks was reset. That number of ticks may reset based on differentschedules for different computing devices (e.g., some devices resetevery few days and others reset every few weeks). A tick may alsorepresent a different amount of time for different systems, so there maybe some device-specific calculations involved to determine how much timeis represented by the reported number of ticks. The result is a timethat is incrementing consistently. Calculating that backwards providesthe uptime, which may be the time the device was last started or thelast time the number of ticks was reset. As such, the uptime generallyremains the same even as ticks increase, until such time that the uptimeis reset.

Such indicators used by identifier server 140 may therefore includesession identifiers (e.g., transport layer security (TLS), securesockets layer (SSL)), transmission control protocol (TCP) identifiers(e.g., uptime, current time, clock skew), internet protocol (IP)address, user agent identifiers, and others. Such indicators may be usedindividually or in any combination (e.g., SSL session identifier and TCPtimestamp) to identify a particular common browser and/or a particularuser device 120 based on common matches. An exemplary embodiment mayselect a certain set of indicators based on their respectivedeterministic value in identifying connections between identifiers fordifferent browsers or devices. For example, a SSL session identifier isunique to the particular session and can therefore be used to map andassociate different mutable browser identifiers for the same browsertogether. Likewise, the combination of current time, uptime, clock skew,and source IP address is unique to a particular device, thereby allowingfor connections to be drawn between different device identifiersassociated with the device.

For example, a particular request to download website may refer to amutable browser identifier that is associated with one or moreindicators (e.g., SSL session identifier). Such SSL session identifiermay be compared to stored information and determined by identifierserver 140 as having been previously used in conjunction with adifferent mutable browser identifier, with an immutable browseridentifier, and/or with a device identifier. Likewise, a TCP timestampassociated with the requesting computing device may be determined byidentifier server 140 as having been previously mapped or used inconjunction with other mutable browser identifiers, with an immutablebrowser identifier, and/or with a device identifier.

Where no stored map existed for the referenced mutable browseridentifier (or any of its associated indicators or identifiers), a newmap may be created. Where a stored map does exist, such stored map maybe updated. As such, maps having one or more of these identifiers may becreated and updated based on newly incoming identifiers (associated withcertain indicators) and matches with stored identifiers (associated withthe same or different indicators). When the identifier server 140 findsthat two different mutable browser identifiers have the same indicator(e.g., SSL session identifier), for example, the identifier server 140may determine that the respective website are using the same browser.The lifespans, availability, and deterministic value of each indicatormay vary across different browsers, user agents, and/or operatingsystems. As such, indicators may be used in combination to increase thelikelihood of finding a match, as well as the level of confidence insuch matches.

In some embodiments, the identifier server 140 may be able to determinethat a request is associated with a particular browser and website (asidentified by a mutable browser identifier). Instead of a “304 notmodified” indicator, the identifier server 140 may return a “200 requestfulfilled” indicator with a new mutable browser identifier, which may bestored by the identifier server 140 in association with or mapped to theoriginal browser identifier. Such a scheme therefore provides formutability of the mutable browser identifier, while maintaining itsassociation with various other identifiers (e.g., device and immutablebrowser identifiers).

In some embodiments, a first party cookie may be used as the persistentidentifier (e.g., mutable browser identifier) for each website. Althougha cookie may persist for a time, such cookie may be changedperiodically. Thereafter, various matching parameters (e.g., SSL anduptime) may be used to identify and to map associated cookies togetheras described in further detail below. In that regard, the identifierserver 140 should be understood as having the ability to use anypersistent identifier to map to other persistent identifiers. Over time,therefore, the map constructed by the identifier server 140 may grow toincorporate new connections and associations between variousidentifiers.

Service providers 150 may include servers or other computing devicesthat may provide various services based on identification of a browser.For example, a service provider 140 may use information regarding repeatvisits to provide targeted advertising to repeat visitors (versusfirst-time visitors).

FIG. 2 is a flowchart illustrating an exemplary method 200 fortimestamp-based matching of identifiers. The method 200 of FIG. 2 may beembodied as executable instructions in a non-transitory computerreadable storage medium including but not limited to a CD, DVD, ornon-volatile memory such as a hard drive. The instructions of thestorage medium may be executed by a processor (or processors) to causevarious hardware components of a computing device hosting or otherwiseaccessing the storage medium to effectuate the method. The stepsidentified in FIG. 2 (and the order thereof) are exemplary and mayinclude various alternatives, equivalents, or derivations thereofincluding but not limited to the order of execution of the same.

In method 200 of FIG. 2, identifier information may be stored in memoryof an identifier server 140, a reference to a browser identifier may bereceived, and it may be determined whether there is a timestamp and IPaddress associated with the referenced browser identifier. If not, themethod may proceed to determine whether the referenced browseridentifier is mapped to a device identifier, and if not, a deviceidentifier may be created and mapped to the referenced browseridentifier. Alternatively, the referenced browser identifier may also bematched to one or more other identifiers (e.g., device, other browsers,and/or websites). Stored information associated with the correspondingstored browser identifier may be updated based on comparing thereferenced browser identifier (and its associated information) withstored browser identifier information (including maps of associatedidentifiers).

In step 205, identifier information may be stored in memory of anidentifier server 140. The stored information may include multipledifferent mutable browser identifiers, immutable browser identifiers,and device identifiers, as well as maps correlating one or more suchidentifiers. For example, a map may associate a particular deviceidentifier with one or more mutable browser identifiers and immutablebrowser identifiers. Such maps may have been generated based onpreviously received information regarding such associations (e.g.,previously received browser identifiers mapped to a particular commondevice identifier), as well as updated over time. Such updates mayinclude not only creating new associations based on newly receivedassociation data, but also updating stored associations based on anymatches to the newly received information.

In step 210, a request for a particular website (e.g., as identified bya URL) may be entered by the user via a browser of a user device 120,which may send such request to the web server 130 associated with thewebsite. The web server 130 provides website content to the browser ofuser device 120. Such website content may be associated with thereference to a browser identifier file. Such a reference may be anotherURL that resolves to identifier server 140. In some embodiments, thereference sent by the web server 140 may pertain to a loader applicationthat is executable to reference the browser identifier file. The browsermay check a local browser cache to find the referenced browseridentifier file.

In step 215, it is determined whether a timestamp (e.g., TCP timestamp)and IP address is associated with the request received in step 210. Ifnot, the method proceeds to step 220, and if yes, the method proceeds tostep 235.

In step 220, it is determined whether the referenced browser identifieris already mapped to a device identifier. Such determination may bebased on the stored maps in memory of the identifier server 140. If so,the method ends. If not, the method may proceed to step 225.

In step 225, a device identifier is created to uniquely identify thecomputing device that referenced the browser identifier.

In step 230, the referenced browser identifier is mapped to the deviceidentifier.

In step 235, it is determined whether the referenced browser identifiercan be mapped to a device identifier. Such step may be performed in amanner similar to step 220. Here, however, if the referenced browseridentifier cannot be mapped to a device identifier, the method mayproceed to step 240. On the other hand, if the referenced browseridentifier can be mapped to a device identifier, the method may proceedto step 245.

In step 240, it is determined whether the timestamp and IP address foundin the same request as the referenced browser identifier can be mappedto a stored device identifier. If not, the method may proceed to step225 (in which the device identifier is created) before proceeding tostep 230 (in which the referenced browser identifier is mapped to thedevice identifier). If the timestamp and IP address found in the samerequest as the referenced browser identifier can be mapped to a storeddevice identifier, however, the method may proceed directly to step 230.

In step 245, it is determined whether a timestamp and IP addressassociated with the mapped device identifier matches the timestamp andIP address received in the same request as the referenced browseridentifier. If there is a match, the method ends. If there is no match,the method may proceed to step 250.

In step 250, it is determined whether there is another, different deviceidentifier (e.g., of all the device identifiers stored at the identifierserver 140) that is associated with a timestamp and IP address matchingthat of the referenced browser identifier. If not, the method proceedsto step 255, and if so, the method proceeds to step 260.

In step 255, stored information regarding the device identifier isupdated to reflect the timestamp and IP address of the referencedbrowser identifier. As noted above, some indicators may have differentdeterministic value. While improbable, it is possible that two differentcomputing devices may have the same timestamp and IP address. As such,the referenced browser identifier may be associated with a differentcomputing device (having a different device identifier) than thecomputing device that that referenced the browser identifier.

In step 260, the stored maps may be updated to remap the referencedimmutable browser identifier (as well as any associated mutable browseridentifiers) to the other device identifier based on the matchingtimestamp and IP address. In some embodiments, remapping may be based onwhich device identifier is older.

FIG. 3 illustrates an exemplary computing system 300 that may be used toimplement an embodiment of the present invention. System 300 of FIG. 3may be implemented in the contexts of the likes of user devices 120A-D,web server 130, identifier server 140, and service provider 150. Thecomputing system 300 of FIG. 3 includes one or more processors 310 andmemory 310. Main memory 310 stores, in part, instructions and data forexecution by processor 310. Main memory 310 can store the executablecode when in operation. The system 300 of FIG. 3 further includes a massstorage device 330, portable storage medium drive(s) 340, output devices350, user input devices 360, a graphics display 370, and peripheraldevices 380.

The components shown in FIG. 3 are depicted as being connected via asingle bus 390. However, the components may be connected through one ormore data transport means. For example, processor unit 310 and mainmemory 310 may be connected via a local microprocessor bus 390, and themass storage device 330, peripheral device(s) 380, portable storagedevice 340, and display system 370 may be connected via one or moreinput/output (I/O) buses 390.

Mass storage device 330, which may be implemented with a magnetic diskdrive or an optical disk drive, is a non-volatile storage device forstoring data and instructions for use by processor unit 310. Massstorage device 330 can store the system software for implementingembodiments of the present invention for purposes of loading thatsoftware into main memory 310.

Portable storage device 340 operates in conjunction with a portablenon-volatile storage medium, such as a floppy disk, compact disk (CD) ordigital video disc (DVD), to input and output data and code to and fromthe computer system 300 of FIG. 3. The system software for implementingembodiments of the present invention may be stored on such a portablemedium and input to the computer system 300 via the portable storagedevice 340.

Input devices 360 provide a portion of a user interface. Input devices360 may include an alpha-numeric keypad, such as a keyboard, forinputting alpha-numeric and other information, or a pointing device,such as a mouse, a trackball, stylus, or cursor direction keys.Additionally, the system 300 as shown in FIG. 3 includes output devices350. Examples of suitable output devices include speakers, printers,network interfaces, and monitors.

Display system 370 may include a liquid crystal display (LCD) or othersuitable display device. Display system 370 receives textual andgraphical information, and processes the information for output to thedisplay device.

Peripherals 380 may include any type of computer support device to addadditional functionality to the computer system. For example, peripheraldevice(s) 380 may include a modem or a router.

The components contained in the computer system 300 of FIG. 3 are thosetypically found in computer systems that may be suitable for use withembodiments of the present invention and are intended to represent abroad category of such computer components that are well known in theart. Thus, the computer system 300 of FIG. 3 can be a personal computer,hand held computing device, telephone, mobile computing device,workstation, server, minicomputer, mainframe computer, or any othercomputing device. The computer can also include different busconfigurations, networked platforms, multi-processor platforms, etc.Various operating systems can be used including Unix, Linux, Windows,Macintosh OS, Palm OS, and other suitable operating systems.

The present invention may be implemented in an application that may beoperable using a variety of devices. Non-transitory computer-readablestorage media refer to any medium or media that participate in providinginstructions to a central processing unit (CPU) for execution. Suchmedia can take many forms, including, but not limited to, non-volatileand volatile media such as optical or magnetic disks and dynamic memory,respectively. Common forms of non-transitory computer-readable mediainclude, for example, a floppy disk, a flexible disk, a hard disk,magnetic tape, any other magnetic medium, a CD-ROM disk, digital videodisk (DVD), any other optical medium, RAM, PROM, EPROM, a FLASHEPROM,and any other memory chip or cartridge.

Various forms of transmission media may be involved in carrying one ormore sequences of one or more instructions to a CPU for execution. A bus(e.g., bus 390) carries the data to system RAM, from which a CPUretrieves and executes the instructions. The instructions received bysystem RAM can optionally be stored on a fixed disk either before orafter execution by a CPU. Various forms of storage may likewise beimplemented as well as the necessary network interfaces and networktopologies to implement the same.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. The descriptions are not intended to limit the scope of theinvention to the particular forms set forth herein. Thus, the breadthand scope of a preferred embodiment should not be limited by any of theabove-described exemplary embodiments. It should be understood that theabove description is illustrative and not restrictive. To the contrary,the present descriptions are intended to cover such alternatives,modifications, and equivalents as may be included within the spirit andscope of the invention as defined by the appended claims and otherwiseappreciated by one of ordinary skill in the art. The scope of theinvention should, therefore, be determined not with reference to theabove description, but instead should be determined with reference tothe appended claims along with their full scope of equivalents.

What is claimed is:
 1. A method for timestamp-based matching ofidentifiers, the method comprising: storing information in memoryregarding one or more maps, wherein each map associates a deviceidentifier with at least one browser identifier, the device identifierunique to an associated computing device; receiving information from acomputing device that has used a browser to download a website, whereinthe downloaded website includes a reference to a browser identifierspecific to the browser; identifying that the received informationincludes a timestamp and an internet protocol (IP) address; determiningthat the timestamp and the IP address in the received informationcorresponds to a device identifier in one of the stored maps, whereinthe corresponding device identifier is specific to the computing device;and updating the stored map associated with the corresponding deviceidentifier based on the referenced browser identifier.